• readme.md (2 hunks)
• src/lexer.ts (8 hunks)
• src/operators.ts (2 hunks)
• src/parser.ts (6 hunks)
• src/translator.ts (2 hunks)
• src/types.ts (2 hunks)
• test/scenarios/comparisons/data.ts (1 hunks)
• test/scenarios/comparisons/template.jt (1 hunks)
• test/scenarios/paths/block.jt (1 hunks)
• test/scenarios/paths/data.ts (1 hunks)
• test/scenarios/paths/json_path.jt (1 hunks)
• test/scenarios/paths/simple_path.jt (1 hunks)
• test/test_engine.ts (1 hunks)

• test/scenarios/comparisons/data.ts
• test/scenarios/paths/simple_path.jt
• test/test_engine.ts

test/scenarios/paths/json_path.jt (3)

2-2: Valid JSON Path expression for selecting the foo property.

---

3-3: Valid JSON Path expression for selecting all items from the items array.

---

4-4: Valid JSON Path expression for selecting items where the property a is greater than 1.

test/scenarios/paths/block.jt (1)

3-4: Correct use of @ symbol to reference the current context in block expressions.

test/scenarios/comparisons/template.jt (2)

21-23: Correct implementation of the in and nin keywords for checking membership and non-membership.

---

24-33: Correct implementation of the contains, size, empty, and subsetof functions for various data structures.

src/operators.ts (2)

26-26: Updated containsStrict function to correctly handle both strings and arrays.

---

77-88: New functions in binaryOperators are correctly implemented and enhance the template engine's capabilities.

test/scenarios/paths/data.ts (1)

72-117: New test scenario for json_path.jt correctly sets up data and expected outputs for testing JSON Path expressions.

src/types.ts (2)

11-16: New keywords added to the Keyword enum are necessary for supporting JSON Path functionality and various utility operations.

---

100-100: Addition of the JSON path type to the PathType enum supports the new JSON Path functionality.

readme.md (1)

219-224: Documentation update correctly introduces the new JSON Path feature as an experimental feature and provides a link to an example.

src/lexer.ts (3)

84-86: New method matchJsonPath correctly matches the ~j token for JSON Path expressions.

---

89-89: Updated method matchPathType correctly includes matching for JSON Path expressions.

---

152-166: New methods matchContains, matchEmpty, matchSize, matchSubsetOf correctly match the respective keywords for new operations.

src/translator.ts (2)

690-696: The implementation of the IN and NOT_IN operators in translateINExpr method is correctly handled. Good use of ternary operations to switch between inclusion and exclusion logic.

---

42-42: The structure and organization of the JsonTemplateTranslator class are well-maintained. The use of the Keyword enum from the types module aligns with the changes made for supporting JSON path syntax.

src/parser.ts (4)

216-217: Ensure correct handling of array filters.

The updated method parseArrayFilterExpr now correctly distinguishes between array and object filter expressions based on the presence of a '?' character, which aligns with the PR's objective to enhance JSON path support.

---

301-303: Validate JSON path support.

The addition of JSON path type handling in parsePathType method correctly implements the new ~j path type as described in the PR summary. This is a crucial part of supporting JSON path syntax in the template engine.

---

312-312: Check integration of parsePathRoot within parsePath.

The integration of parsePathRoot within parsePath method is correctly done. It ensures that the root of the path is parsed based on the path type, which is essential for the correct functioning of path expressions in the template engine.

---

557-579: Review changes to parseArrayFilterExpr.

The modifications to parseArrayFilterExpr to handle different types of filters (array, object) based on the presence of specific tokens (?, *) are in line with the PR's objectives to enhance JSON path support. This change improves the flexibility and accuracy of filter parsing.

• src/parser.ts (6 hunks)
• src/translator.ts (3 hunks)
• src/types.ts (4 hunks)

• src/parser.ts
• src/translator.ts
• src/types.ts

• test/scenarios/paths/data.ts (1 hunks)
• test/scenarios/paths/json_path.jt (1 hunks)

• test/scenarios/paths/data.ts
• test/scenarios/paths/json_path.jt

• src/parser.ts (7 hunks)
• test/scenarios/paths/data.ts (1 hunks)
• test/scenarios/paths/json_path.jt (1 hunks)

• test/scenarios/paths/data.ts
• test/scenarios/paths/json_path.jt

src/parser.ts (3)

311-313: Ensure that JSON path type is correctly recognized and handled.

This script checks for the usage of PathType.JSON across the codebase to ensure it is handled correctly in all relevant scenarios.

---

570-590: Review the logic for determining exprType in parseArrayFilterExpr.

This script checks how parseArrayFilterExpr is used in test cases, particularly focusing on the logic that determines exprType based on the lexer's state.

---

219-220: Ensure correct handling of array filters.

This script checks how parseArrayFilterExpr is used in test scenarios to ensure it handles different cases correctly.

Verification successful

---

The test files ./test/scenarios/filters/data.ts and ./test/scenarios/bad_templates/data.ts contain scenarios that involve array filters and potential errors related to array expressions. Additionally, ./test/scenario.test.ts includes a framework for running these scenarios.

• ./test/scenarios/filters/data.ts includes a scenario with templatePath: 'array_filters.jt'.
• ./test/scenarios/bad_templates/data.ts includes a scenario with templatePath: 'bad_array_coalese_expr.jt'.

These scenarios suggest that array filters are indeed being tested, either directly or indirectly, through these templates.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the correct handling of array filters in various scenarios.

# Test: Search for usage of `parseArrayFilterExpr` in test scenarios.
rg --type typescript $'parseArrayFilterExpr' ./test

Length of output: 85

---

---

Script:

#!/bin/bash
# Description: Verify the correct handling of array filters in various scenarios.

# Test: Search for usage of `parseArrayFilterExpr` in test scenarios.
rg --type ts 'parseArrayFilterExpr' ./test

Length of output: 42

---

---

Script:

#!/bin/bash
# Description: Verify the correct handling of array filters by checking the definition and usage of `parseArrayFilterExpr`.

# Search for the definition of `parseArrayFilterExpr`.
rg 'parseArrayFilterExpr' --type ts

# Search for the usage of `parseArrayFilterExpr` throughout the codebase.
rg 'parseArrayFilterExpr' --type ts

Length of output: 377

---

---

Script:

#!/bin/bash
# Description: Verify the correct handling of array filters by checking for test cases involving array filters.

# Search for test cases involving array filters.
rg 'array filter' --type ts ./test

Length of output: 36

---

---

Script:

#!/bin/bash
# Description: Verify the correct handling of array filters by checking for test cases involving the lexer matching '['.

# Search for test cases involving the lexer matching '['.
rg "lexer.match('\\[')" --type ts ./test

Length of output: 47

---

---

Script:

#!/bin/bash
# Description: Verify the correct handling of array filters by checking for test cases involving array expressions or filters.

# Search for test cases involving array expressions or filters.
rg 'array' --type ts ./test

Length of output: 269

---

---

Script:

#!/bin/bash
# Description: Verify the correct handling of array filters by inspecting test cases in specific files.

# Display the contents of the relevant test files.
cat ./test/scenarios/filters/data.ts
cat ./test/scenarios/bad_templates/data.ts
cat ./test/scenario.test.ts

Length of output: 4935

• .gitignore (1 hunks)
• .nvmrc (1 hunks)
• src/constants.ts (1 hunks)
• src/engine.ts (5 hunks)
• src/parser.ts (9 hunks)
• src/translator.ts (3 hunks)
• src/types.ts (5 hunks)
• src/utils/common.test.ts (1 hunks)
• src/utils/common.ts (1 hunks)
• src/utils/converter.test.ts (1 hunks)
• src/utils/converter.ts (1 hunks)
• src/utils/index.ts (1 hunks)
• test/scenarios/mappings/data.ts (1 hunks)
• test/scenarios/mappings/mappings.json (1 hunks)
• test/types.ts (2 hunks)
• test/utils/scenario.ts (1 hunks)

• .gitignore
• .nvmrc
• src/constants.ts
• src/utils/index.ts
• test/scenarios/mappings/mappings.json

src/utils/common.test.ts (1)

5-66: Ensure comprehensive test coverage for CommonUtils.

The test cases appear to cover various scenarios for each method in CommonUtils, ensuring that the utility functions behave as expected across different inputs.

src/types.ts (2)

11-16: Confirm the addition of new keywords.

Ensure that the newly added keywords (NOT_IN, CONTAINS, SUBSETOF, EMPTY, SIZE) are properly integrated and utilized in the lexer and parser as intended.

---

Line range hint 77-101: Validate the integration of new SyntaxType and PathType additions.

Check that the new syntax types (ALL_FILTER_EXPR, OBJECT_INDEX_FILTER_EXPR, RANGE_FILTER_EXPR, OBJECT_FILTER_EXPR, ARRAY_FILTER_EXPR) and the new path type (JSON) are correctly handled in the parser and translator modules.

src/translator.ts (1)

724-724: Ensure consistent handling of different filter types in translateArrayFilterExpr.

The method translateArrayFilterExpr handles different types of filters, but it's crucial to ensure that all potential filter types are handled correctly. Please verify that all filter types that should be supported are indeed being handled here. If some are missing, consider adding the necessary logic.

src/parser.ts (2)

48-48: Initialize pathTypesStack directly in its declaration.

This change simplifies the initialization of pathTypesStack by directly assigning an empty array, which is a cleaner approach.

---

309-311: Ensure correct handling of JSON path type.

The addition of JSON path type handling in parsePathType method aligns with the PR's objective to support JSON path syntax.

• src/engine.ts (4 hunks)
• src/parser.ts (14 hunks)
• src/translator.ts (8 hunks)
• src/utils/common.test.ts (1 hunks)
• src/utils/common.ts (1 hunks)
• src/utils/converter.test.ts (1 hunks)
• src/utils/converter.ts (1 hunks)

• src/utils/common.test.ts
• src/utils/converter.test.ts

src/parser.ts (3)

48-48: Initialize pathTypesStack directly in its declaration.

This initialization ensures that pathTypesStack is never undefined, which simplifies the handling of this array throughout the class.

---

269-285: Refactor parsePathRoot to simplify token handling.

This change uses a switch statement to handle different cases, which can be easier to read and maintain.

---

573-593: Refactor parseArrayFilterExpr to handle object filter expressions.

This change introduces handling for object filter expressions within the parseArrayFilterExpr method, which is a significant enhancement for parsing capabilities.

• src/lexer.ts (12 hunks)
• src/operators.ts (2 hunks)
• src/parser.ts (16 hunks)
• src/translator.ts (8 hunks)
• src/types.ts (6 hunks)
• test/scenarios/bad_templates/bad_regex.jt (1 hunks)
• test/scenarios/bad_templates/data.ts (1 hunks)
• test/scenarios/comparisons/data.ts (1 hunks)
• test/scenarios/comparisons/template.jt (1 hunks)

• src/operators.ts
• test/scenarios/comparisons/template.jt

test/scenarios/comparisons/data.ts (1)

26-39: The additions to the test data are consistent with the existing structure.

test/scenarios/bad_templates/data.ts (1)

28-31: The addition of the new scenario for testing invalid regular expressions is consistent with the existing structure.

src/types.ts (1)

11-16: The updates to enums and interfaces align well with the new features introduced in the PR.

Also applies to: 38-38, 78-78, 102-102, 197-198, 204-204, 267-275

src/lexer.ts (1)

84-86: The additions and updates to the methods in JsonTemplateLexer are well-implemented and support the new JSON path syntax and other features effectively.

Also applies to: 89-89, 93-93, 152-166, 169-169, 282-287, 322-323, 346-346, 647-655, 665-695

src/translator.ts (2)

42-42: Use explicit type imports for clarity and maintainability.

---

690-696: Refactor the IN and NOT IN logic for clarity.

src/parser.ts (2)

48-48: Initialization of pathTypesStack directly in its declaration is a good practice.

---

Line range hint 1181-1181: Use Number.parseFloat and Number.parseInt instead of the equivalent global functions to avoid potential issues in non-browser environments.
[REFACTOR_SUGGESTion]

- parseFloat(val),
- parseInt(val, 10),
- parseFloat(val),
+ Number.parseFloat(val),
+ Number.parseInt(val, 10),
+ Number.parseFloat(val),

Also applies to: 1187-1187, 1196-1196

• src/lexer.ts (12 hunks)
• src/operators.ts (2 hunks)
• src/parser.ts (16 hunks)
• src/translator.ts (7 hunks)
• src/types.ts (6 hunks)
• test/scenarios/comparisons/data.ts (1 hunks)
• test/scenarios/comparisons/template.jt (1 hunks)

• test/scenarios/comparisons/template.jt

test/scenarios/comparisons/data.ts (1)

26-41: The additions to the test scenarios are consistent with the expected outputs.

src/operators.ts (2)

26-26: The update to containsStrict to handle both strings and arrays enhances its functionality and aligns with the new JSON path features.

---

77-93: The addition of new binary operators for size, empty, and subsetof is correctly implemented and supports the new JSON path operations.

src/types.ts (3)

11-18: The addition of new keywords to the Keyword enum supports the expanded functionality of the JSON path syntax.

---

104-104: The addition of the JSON path type to the PathType enum is crucial for supporting JSON path queries.

---

199-206: The new interfaces for filter expressions are well-defined and support the complex querying capabilities introduced.

src/lexer.ts (2)

84-93: The addition of matchJsonPath and the update to matchPathType and matchPath correctly implement the lexer's ability to recognize the new JSON path type.

---

152-182: The methods added to match the new keywords (contains, empty, size, subsetof, anyof, noneof, notIN) are correctly implemented and enhance the lexer's capabilities.

src/parser.ts (1)

48-48: Refactor to initialize pathTypesStack directly in its declaration.

• src/operators.ts (3 hunks)
• src/parser.ts (16 hunks)
• src/translator.ts (12 hunks)
• src/types.ts (7 hunks)
• test/scenarios/functions/array_functions.jt (1 hunks)
• test/scenarios/functions/data.ts (1 hunks)
• test/scenarios/standard_functions/data.ts (1 hunks)
• test/scenarios/standard_functions/template.jt (1 hunks)

• test/scenarios/functions/array_functions.jt
• test/scenarios/standard_functions/template.jt

test/scenarios/standard_functions/data.ts (1)

1-1: The import is correctly used as a type, which is a good practice in TypeScript to avoid runtime import overhead.

test/scenarios/functions/data.ts (1)

1-1: The import is correctly used as a type, which is a good practice in TypeScript to avoid runtime import overhead.

src/operators.ts (2)

26-26: The update to containsStrict to include arrays in its checks aligns with the new JSON path functionalities.

---

77-79: The addition of new operators for JSON path operations such as =~, size, empty, subsetof, and anyof is well-implemented and enhances the flexibility of the engine.

Also applies to: 86-93

src/types.ts (1)

11-18: The additions to the enums and new interface definitions are well-aligned with the new JSON path functionalities and enhance the type safety of the engine.

Also applies to: 40-40, 80-80, 104-104, 199-199, 206-206, 269-277

src/translator.ts (2)

10-10: The addition of new imports and the handling of standard functions are well-implemented. The logic to include functions only if they are used is a good performance optimization.

Also applies to: 43-43, 52-53, 95-98

---

720-720: Address past comments regarding type safety and the use of switch statements for clarity.

Also applies to: 722-722, 743-743

src/parser.ts (2)

48-48: Initialization of pathTypesStack directly in its declaration is a good practice.

---

228-228: Avoid assignments within expressions to enhance code readability and maintainability.

- while ((newParts = toArray(this.parsePathPart()))) {
+ newParts = toArray(this.parsePathPart());
+ while (newParts) {

Likely invalid or redundant comment.

• src/utils/converter.ts (1 hunks)

src/utils/converter.ts (6)

15-20: Function CreateObjectExpression correctly initializes an ObjectExpression. Well done!

---

22-36: Function findOrCreateObjectPropExpression efficiently manages object properties. Good use of array methods and conditional logic.

---

38-55: Function processArrayIndexFilter correctly handles different scenarios based on the type of the current output property AST. Efficient handling of array expressions.

---

57-82: Function processAllFilter effectively manipulates path expressions based on the presence of object filters. Good use of array methods and conditional logic.

---

84-118: Function processFlatMapping effectively processes flat mappings and handles different types of selectors and filters. Good integration of helper functions.

---

122-130: Function convertToObjectMapping correctly initializes and builds an object expression from flat mappings. Efficient use of iteration and helper functions.

• src/operators.ts (4 hunks)
• src/parser.ts (18 hunks)
• test/scenarios/bad_templates/object_with_invalid_key.jt (1 hunks)
• test/scenarios/comparisons/anyof.jt (1 hunks)
• test/scenarios/comparisons/contains.jt (1 hunks)
• test/scenarios/comparisons/data.ts (1 hunks)
• test/scenarios/comparisons/empty.jt (1 hunks)
• test/scenarios/comparisons/ends_with.jt (1 hunks)
• test/scenarios/comparisons/ends_with_ignore_case.jt (1 hunks)
• test/scenarios/comparisons/eq.jt (1 hunks)
• test/scenarios/comparisons/ge.jt (1 hunks)
• test/scenarios/comparisons/gte.jt (1 hunks)
• test/scenarios/comparisons/in.jt (1 hunks)
• test/scenarios/comparisons/le.jt (1 hunks)
• test/scenarios/comparisons/lte.jt (1 hunks)
• test/scenarios/comparisons/ne.jt (1 hunks)
• test/scenarios/comparisons/noneof.jt (1 hunks)
• test/scenarios/comparisons/not_in.jt (1 hunks)
• test/scenarios/comparisons/regex.jt (1 hunks)
• test/scenarios/comparisons/size.jt (1 hunks)
• test/scenarios/comparisons/starts_with.jt (1 hunks)
• test/scenarios/comparisons/starts_with_ignore_case.jt (1 hunks)
• test/scenarios/comparisons/string_contains_ignore_case.jt (1 hunks)
• test/scenarios/comparisons/string_eq.jt (1 hunks)
• test/scenarios/comparisons/string_eq_ingore_case.jt (1 hunks)
• test/scenarios/comparisons/string_ne.jt (1 hunks)
• test/scenarios/comparisons/string_ne_ingore_case.jt (1 hunks)
• test/scenarios/comparisons/subsetof.jt (1 hunks)

• src/operators.ts (no review received)

• test/scenarios/bad_templates/object_with_invalid_key.jt
• test/scenarios/comparisons/anyof.jt
• test/scenarios/comparisons/contains.jt
• test/scenarios/comparisons/empty.jt
• test/scenarios/comparisons/ends_with.jt
• test/scenarios/comparisons/ends_with_ignore_case.jt
• test/scenarios/comparisons/eq.jt
• test/scenarios/comparisons/ge.jt
• test/scenarios/comparisons/gte.jt
• test/scenarios/comparisons/in.jt
• test/scenarios/comparisons/le.jt
• test/scenarios/comparisons/lte.jt
• test/scenarios/comparisons/ne.jt
• test/scenarios/comparisons/noneof.jt
• test/scenarios/comparisons/not_in.jt
• test/scenarios/comparisons/regex.jt
• test/scenarios/comparisons/size.jt
• test/scenarios/comparisons/starts_with.jt
• test/scenarios/comparisons/starts_with_ignore_case.jt
• test/scenarios/comparisons/string_contains_ignore_case.jt
• test/scenarios/comparisons/string_eq.jt
• test/scenarios/comparisons/string_eq_ingore_case.jt
• test/scenarios/comparisons/string_ne.jt
• test/scenarios/comparisons/string_ne_ingore_case.jt
• test/scenarios/comparisons/subsetof.jt

test/scenarios/comparisons/data.ts (24)

5-10: The scenario for anyof.jt is correctly structured with appropriate true and false conditions.

---

12-17: The scenario for contains.jt is correctly structured with appropriate true and false conditions.

---

19-24: The scenario for empty.jt is correctly structured with appropriate true and false conditions.

---

26-31: The scenario for string_contains_ignore_case.jt is correctly structured with appropriate true and false conditions.

---

33-38: The scenario for ends_with.jt is correctly structured with appropriate true and false conditions.

---

40-45: The scenario for ends_with_ignore_case.jt is correctly structured with appropriate true and false conditions.

---

47-52: The scenario for eq.jt is correctly structured with appropriate true and false conditions.

---

54-59: The scenario for ge.jt is correctly structured with appropriate true and false conditions.

---

61-66: The scenario for gte.jt is correctly structured with appropriate true and false conditions.

---

68-73: The scenario for in.jt is correctly structured with appropriate true and false conditions.

---

75-80: The scenario for le.jt is correctly structured with appropriate true and false conditions.

---

82-87: The scenario for lte.jt is correctly structured with appropriate true and false conditions.

---

89-94: The scenario for ne.jt is correctly structured with appropriate true and false conditions.

---

96-101: The scenario for noneof.jt is correctly structured with appropriate true and false conditions.

---

103-108: The scenario for not_in.jt is correctly structured with appropriate true and false conditions.

---

110-115: The scenario for regex.jt is correctly structured with appropriate true and false conditions.

---

117-122: The scenario for size.jt is correctly structured with appropriate true and false conditions.

---

124-129: The scenario for starts_with.jt is correctly structured with appropriate true and false conditions.

---

131-136: The scenario for starts_with_ignore_case.jt is correctly structured with appropriate true and false conditions.

---

138-143: The scenario for string_eq.jt is correctly structured with appropriate true and false conditions.

---

145-150: The scenario for string_ne.jt is correctly structured with appropriate true and false conditions.

---

152-157: The scenario for string_eq_ingore_case.jt is correctly structured with appropriate true and false conditions.

---

159-164: The scenario for string_ne_ingore_case.jt is correctly structured with appropriate true and false conditions.

---

173-177: The scenario for subsetof.jt is correctly structured with appropriate true and false conditions.

• src/engine.ts (3 hunks)
• src/lexer.ts (12 hunks)
• src/parser.ts (17 hunks)
• src/reverse_translator.ts (1 hunks)
• src/translator.ts (15 hunks)
• src/types.ts (10 hunks)
• src/utils/common.ts (1 hunks)
• src/utils/converter.ts (1 hunks)
• src/utils/transalator.ts (1 hunks)
• test/scenarios/context_variables/filter.jt (1 hunks)
• test/scenarios/filters/object_filters.jt (1 hunks)
• test/scenarios/filters/object_indexes.jt (1 hunks)
• test/scenarios/objects/template.jt (2 hunks)
• test/scenarios/return/data.ts (1 hunks)
• test/scenarios/return/return_no_value.jt (1 hunks)
• test/utils/scenario.ts (1 hunks)

• test/scenarios/context_variables/filter.jt
• test/scenarios/filters/object_filters.jt
• test/scenarios/objects/template.jt
• test/scenarios/return/return_no_value.jt

test/scenarios/filters/object_indexes.jt (1)

7-7: The use of spread syntax with object indexing is innovative, but the syntax {!["d"]} is unclear. Please clarify or document its intended functionality.

src/utils/transalator.ts (1)

4-10: The function translateLiteral is well-implemented with clear handling of string types. Ensure that all possible TokenType values are appropriately handled.

test/scenarios/return/data.ts (1)

23-28: Ensure that the scenarios are correctly capturing the intended behavior, especially with different inputs leading to the same output.

Verification successful

---

The extracted scenarios show that different inputs (3 and 2) are indeed leading to the same output (1) for the template 'return_value.jt'. This confirms that the scenarios are capturing the intended behavior of different inputs leading to the same output.

• templatePath: 'return_value.jt', input: 3, output: 1
• templatePath: 'return_value.jt', input: 2, output: 1

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the scenarios for 'return_value.jt'.
# Test: Check if different inputs intentionally lead to the same output.
cat test/scenarios/return/data.ts | grep 'return_value.jt'

Length of output: 132

---

---

Script:

#!/bin/bash
# Description: Extract and display the full scenarios for 'return_value.jt' to verify inputs and outputs.
awk '/templatePath: .return_value.jt./,/},/' test/scenarios/return/data.ts

Length of output: 218

src/engine.ts (1)

25-28: The method compileAsAsync is correctly updated to handle FlatMappingPaths[]. Ensure that the CreateAsyncFunction is robust against various input types.

src/utils/converter.ts (4)

16-21: The function CreateObjectExpression is well-defined and follows best practices for creating a new object expression.

---

23-37: The function findOrCreateObjectPropExpression effectively ensures that a property exists in the object, creating it if necessary. This is a good use of the find and conditional creation pattern.

---

39-56: The function processArrayIndexFilter correctly handles the case where the current property is not an array by initializing it as one. It also handles missing elements at specific indices well.

---

124-132: The function convertToObjectMapping serves as a good entry point for converting flat mappings to object expressions. It is concise and delegates complexity to other functions effectively.

src/types.ts (5)

11-18: The additions to the Keyword enum are correctly implemented and align with the new features introduced in the lexer.

---

40-40: The addition of REGEXP to the TokenType enum is appropriate given the new regular expression handling in the lexer.

---

Line range hint 80-104: The updates to SyntaxType and PathType enums are correctly implemented and necessary for the new JSON path functionality.

---

130-132: The PathOptionsExpression interface is a good addition for type safety and clarity in handling path options within expressions.

---

204-205: The AllFilterExpression interface is correctly defined as an empty interface, which is appropriate for its usage in filtering expressions.

src/reverse_translator.ts (2)

39-110: The JsonTemplateReverseTranslator class is well-structured and the translate method effectively handles different expression types using a switch statement.

---

112-462: The translation methods are well-implemented, each handling a specific type of expression. The use of helper methods like translateWithWrapper enhances readability and maintainability.

src/lexer.ts (2)

Line range hint 84-182: The methods added to the JsonTemplateLexer class for matching various new keywords and path types are correctly implemented and follow the established pattern in the lexer.

---

152-182: The methods for matching new keywords related to the JSON path functionality (matchContains, matchEmpty, etc.) are correctly implemented. These methods enhance the lexer's capability to recognize more complex expressions.

Files that changed from the base of the PR and between a9e591a and 71f3b06.

• src/reverse_translator.ts (1 hunks)

src/reverse_translator.ts (40)

1-34: Use type-only imports for types that are not used as values to clarify their usage and optimize bundling.

---

39-44: Initialization of options in the constructor is straightforward and correct.

---

46-50: The method translate correctly formats the code string by replacing unnecessary spaces between dots. This is a good practice for code cleanliness.

---

52-115: The translateExpression method handles a wide range of expression types, ensuring that each type is directed to its specific translation method. This is a good example of using a switch-case for type discrimination.

---

118-120: The method translateArrayFilterExpression correctly delegates the translation of the filter expression. This maintains modularity in the code.

---

122-134: The method translateRangeFilterExpression constructs a range filter expression in a clear and concise manner. The use of an array to build the string is efficient for this purpose.

---

136-138: The method translateArrayIndexFilterExpression is concise and delegates the translation to another method, maintaining simplicity and reusability.

---

140-149: The method translateObjectIndexFilterExpression effectively constructs the object index filter expression, handling the exclude flag correctly.

---

151-162: The method translateSelectorExpression handles string properties correctly by escaping them when necessary. This is crucial for preventing injection attacks or errors in the output.

---

164-166: The method translateWithWrapper is a utility function that correctly wraps an expression with specified prefixes and suffixes, demonstrating good use of template literals.

---

168-176: The method translateObjectFilterExpression uses conditional logic to determine the correct wrapper based on the filter type and path options. This is a good practice for handling multiple conditions.

---

178-180: The method translateLambdaArgExpression is straightforward and correctly formats the lambda argument expression.

---

182-184: The method translateLoopControlExpression is simple and correctly returns the control expression.

---

186-206: The method translateLoopExpression constructs the loop expression comprehensively, handling initialization, test, and update expressions correctly.

---

208-210: The method translateReturnExpression correctly formats the return expression, ensuring that it defaults to an empty expression if none is provided.

---

212-214: The method translateThrowExpression is implemented correctly, ensuring that the thrown value is translated properly.

---

216-218: The method translateExpressions efficiently handles multiple expressions, joining them with a specified separator. This is a good use of the map function for transformation.

---

220-222: The method translateLambdaFunctionExpression is concise and correctly delegates the body translation, maintaining clarity and simplicity.

---

224-236: The method translateRegularFunctionExpression constructs the function expression clearly, handling parameters and the function body effectively.

---

238-252: The method translateFunctionExpression handles both regular and lambda functions, demonstrating flexibility in function translation based on the function type.

---

254-275: The method translateFunctionCallExpression effectively constructs the function call expression, handling different scenarios for object and parent presence.

---

277-283: The method translateAssignmentExpression correctly constructs the assignment expression, ensuring that the path, operator, and value are properly formatted.

---

285-298: The method translateDefinitionExpression handles variable definitions effectively, particularly managing the scenario where variables are derived from an object.

---

300-317: The method translateConditionalExpression is implemented well, handling the conditional logic and formatting the expression correctly.

---

319-330: The method translatePathType uses a switch-case to handle different path types, returning the appropriate string representation for each.

---

332-340: The method translatePathRootString handles special cases for BINDINGS_PARAM_KEY and DATA_PARAM_KEY correctly, ensuring that the appropriate symbols are returned based on the path type.

---

342-355: The method translatePathRoot effectively handles both string and expression types for the root, demonstrating flexibility in handling path roots.

---

357-373: The method translatePathOptions constructs the path options string correctly, handling optional properties like item and index.

---

375-393: The method translatePathParts constructs the path parts string effectively, handling different types of expressions and their options.

---

395-404: The method translatePathExpression comprehensively constructs the path expression, integrating type, root, options, and parts translation effectively.

---

407-412: The method translateIncrementExpression handles both postfix and prefix increment operations correctly, demonstrating flexibility in expression formatting.

---

414-416: The method translateUnaryExpression is implemented correctly, ensuring that the unary operator and its argument are formatted properly.

---

418-424: The method translateBlockExpression constructs the block expression effectively, handling multiple statements within a block.

---

426-428: The method translateSpreadExpression correctly handles the spread operator, demonstrating good use of template literals for expression formatting.

---

430-435: The method translateObjectExpression constructs the object expression clearly, handling properties and ensuring proper formatting with new lines.

---

438-451: The method translateObjectPropExpression handles both string and expression types for keys, demonstrating flexibility and correctness in property translation.

---

454-460: The method translateArrayExpression constructs the array expression effectively, handling elements and ensuring proper formatting with commas.

---

462-464: The method translateLiteralExpression correctly delegates to the translateLiteral utility function, ensuring that literals are translated based on their type and value.

---

466-468: The method translateStatementsExpression handles multiple statements effectively, joining them with a newline and semicolon for clarity.

---

470-474: The method translateBinaryExpression constructs the binary expression correctly, ensuring that the operands and operator are formatted properly.

Files that changed from the base of the PR and between 71f3b06 and 6b5269e.

• src/engine.ts (3 hunks)
• src/reverse_translator.ts (1 hunks)
• src/types.ts (10 hunks)
• src/utils/converter.ts (1 hunks)
• test/scenarios/mappings/data.ts (1 hunks)
• test/scenarios/mappings/invalid_mappings.json (1 hunks)

• test/scenarios/mappings/invalid_mappings.json

• test/scenarios/mappings/data.ts

src/engine.ts (1)

25-28: Refactor to avoid using this in static methods, which can lead to confusion and potential errors.

- return CreateAsyncFunction(DATA_PARAM_KEY, BINDINGS_PARAM_KEY, this.translate(templateOrExpr, options));
+ return CreateAsyncFunction(DATA_PARAM_KEY, BINDINGS_PARAM_KEY, JsonTemplateEngine.translate(templateOrExpr, options));

Likely invalid or redundant comment.

src/types.ts (2)

40-40: Validate the new token and syntax types to ensure they are properly used in lexer and parser implementations.

Also applies to: 80-80, 103-104

Verification successful

---

The new token and syntax types (REGEXP, ALL_FILTER_EXPR, JSON, UNKNOWN) are properly integrated and used in the lexer and parser implementations. Here are the key points:

• Lexer Implementation:

  • The REGEXP token type is used in the lexer to identify and handle regular expressions.
  • The UNKNOWN token type is used to handle unknown tokens and throw appropriate errors.

• Parser Implementation:

  • The ALL_FILTER_EXPR syntax type is used in the parser to handle specific filter expressions.
  • The JSON path type is used to handle JSON path types in the parser.

The code snippets confirm that these types are correctly implemented and used in the relevant contexts.

• src/lexer.ts:

  • REGEXP: Lines around token.type === TokenType.REGEXP
  • UNKNOWN: Lines around JsonTemplateLexer.throwError(MESSAGES.UNKNOWN_TOKEN)

• src/parser.ts:

  • ALL_FILTER_EXPR: Lines around type: SyntaxType.ALL_FILTER_EXPR
  • JSON: Lines around return this.createPathResult(PathType.JSON)

Scripts executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Check for proper usage of new token and syntax types.

# Test: Search for the usage of new types. Expect: Proper implementation in lexer and parser.
rg --type ts 'REGEXP|ALL_FILTER_EXPR|JSON|UNKNOWN'

Length of output: 2215

---

---

Script:

#!/bin/bash
# Extract relevant code snippets from lexer and parser implementations for detailed examination.

# Extract lines around the usage of REGEXP and UNKNOWN in lexer
rg --type ts -A 5 -B 5 'REGEXP|UNKNOWN' src/lexer.ts

# Extract lines around the usage of ALL_FILTER_EXPR and JSON in parser
rg --type ts -A 5 -B 5 'ALL_FILTER_EXPR|JSON' src/parser.ts

Length of output: 3323

---

11-18: Ensure the newly added keywords in the Keyword enum are correctly implemented throughout the codebase.

Verification successful

---

The new keywords in the Keyword enum are correctly implemented throughout the codebase. They are used in the following files:

• src/lexer.ts: For matching keyword values.
• src/parser.ts: For parsing operations.
• src/reverse_translator.ts: For translating expressions.
• src/utils/common.test.ts: For testing purposes.

These usages indicate that the new keywords are integrated into the codebase and are being tested.

Scripts executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Description: Verify the usage of new keywords in the codebase.

# Test: Search for the new keywords. Expect: Proper implementation in relevant files.
rg --type ts 'NOT_IN|CONTAINS|SUBSETOF|ANYOF|NONEOF|EMPTY|SIZE'

Length of output: 1678